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ABSTRACT 



Architecture ot a Ring coramunication network based on 
the Distributed Computing System (DCS) at the University of 
California, Irvine is presented. Control of the network is 
distributed in time among the active processors for 
reliability. A pseudo-bipolar violation protocol, mcdeled 
after the farmer and Kewhall ring at Bell Labs, is used to 
implement synchronization, control passing, and variable 
length messages. The prototype system is designed to make 
extensive use of micro-computers for flexib.ility in design. 
Ring organization and protocol are discussed with the major 
emphasis on the use of an INTEL MCS-8 Micro-Computer at the 
interface of a teletype to the ring. The MCS-8 program is 



written in PL/M-a higher 
micr o-compu ters. 



level language for INTEL'S 
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I- IEIM AUCTION 

A project is underway at the Naval Postgraduate School 
to establish a local ring- structured communication network. 
This network will link present and future computers on the 
NPS grounds to provide a more efficient utilization of 
computing resources. This paper is a first report on the 
progress of that project. 

Investigation of several existing computer networks led 
to the selection of the Distributed Computing System (DCS) 
developed at the University of California at Irvine as a' 

model. The mjjLn f ea tu res of the DCS that made it suitable 

as a model are re l labili ty , relatively low c ost , and its 

p roce ssor "in dependent communication's protocol. The ring 

structure of the DCS was retained along with the distributed 
control philosophy. The main differences between the 
proposed system and DCS are (1) the use of micro- computers 
at the ring interface (RI) to replace as many RI hardware 
functions as possible with software, and (2) the bipolar 
violation concept for sta rt-of -message (SOM) and 
end-of-message (EOM) indication, synchronization (SYN), and 
control (CTL) passing. These violations will be referred to 
as "tokens." 

System topology and protocol are discussed and the use 
of a micro-computer in the prototype system is presented. 
This thesis concentrates on the use of an INTEL MCS-8 
micro-processor at the interface of a host to the 
communication ring. The micro-computer acts as a buffer 
between a host and the Ring Interface. It can control host 
communication with the ring and free the host processor from 
most of the "handshaking" required for communication with 
other processors. The term "smart terminal" has been used 
to describe the role of the micro-computer. A specific 
example incorporating a teletype (ASR-33) as the host is 
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several 



programmed in PL/rt and implemented on the MCS-8. 

Micro-computers were chosen for 3 reas ons: 

1. A V a i l a b i jLi t j ♦ The school has 
micro-computers at its disposal (INTEL HCS-h and MCS-8). 

2. Flexibility. Micro-computers provide 

flexibility in design not found in a hardware-only 
configuration at the ring interfaces. Modifications to 
host/Ring Interface protocol can be accomplished by altering 
micro-processor software instead of changing hardware 
des ign . 



3. High 
INTEL'S 8- bit mi 
written in ANSI st 
IBH-360/67 and XD 
School, PL/M is d 
retains the effi 
language. 



Level Program 
cro-computers i 
andard PORTRAIT I 
S-9300 computers 
esigned for the 
ciency and con 



ming Language. PL/M for 
s supported by a compiler 
V. It is available on the 
at tne Naval Postrgaduate 
systems programmer and 
trol of an assembly level 



8 



II 



SYSTEM TOPOLOGY 



A. REQUIREMENTS 

The main requirement of the system is to 
reliable, low cost communication link between th 
systems presently located at NPS and to be flexib 
to add future computer systems to this netwo 
having to modify network protocol (and therefore R 
Reliability was also considered important 
standpoint of possible applications of this com 
structure to the operational Navy. 

T • Reliab il ity 

Reliability is achieved by distributing 
the ring amoung the active users with a fail-soft 
of control. No single processor has the responsi 
the control of the ring. Control is distributed 
over all the processors in the network. The fail 
processor will not hinder communication bet 
remaining processors. 

The ring i-s never idle for more then shor 
at a time. If processes are not in direct comm 
the ring idles by relaying control (CTL) token 
active nodes. Maintaining the ring in a semiac 
provides a positive control mechanism that mini 
time required to recognize control failures, 
light-off, the first node to be activated will 
broadcasting violation tokens. This is strictly 
of the Ring Interface and is independent of host s 
node with a message for transmission will take 
the ring by replacing the control token (CTL 
start-of- message (SOM) token. After message trans 



provide a 
e computer 
le enough 
rk without 
I design) . 

from the 
munica tion 



control of 
philosophy 
bility for 
in time 
ure of any 
ween the 

t periods 
u nication , 
s between 
tive state 
mizes the- 
At system 
commen ce 
a function 
tatus. A 
control of 
) with a 
mission is 
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complete, the transmitting node will send a CTL token and 
wait until it either recognizes an SOtl from another node or 
its host has another message to transmit. If the node that 
is currently transmitting (either a message or token) should 
for some reason fail, the remaining nodes will go into a 
"time-out" state. An interface completing its time-out 
without receiving an SYN or CTL violation token vfill assume 
control of the ring. In effect each active node monitors 
the control of the ring. Any node can take control if 
necessary to insure control reliability. 

Each interface has a unique delay time with enough 
separation in times to prevent two from both simultaneously 
attempting to transmit tokens. An RI that times-out, 
transmits an SYN token, and fails to receive its transmitted 
token, will signal its host. The host can then make the 
decision on whether to exit from the ring. An alternate 
procedure could be to switch to a standby ring and attempt 
to join this ring in a normal manner. 



2 • width Req uireme nts 



A range of devices from low speed to high speed must 
be accomodated. The limiting factor in the system is the 
slowest rate at which messages can be placed onto or taken 
off the ring. In the prototype system the limiting component 
is the MCS-8 and its relatively long instruction cycle time 
(12.5 microseconds). Specifically, to make successive 
8-bit bytes available to the Ring Interface for 
transmission, the program requires 59 machine cycles. This 
limits ring speed to approximately 10Kb (Kilobits per 
second). Even at this relatively slow speed, a. number of 
printers and card readers could be driven. A remote batch 
entry system for the IBH-360 will be attempted in the near 
future using the NFS Ring. 10Kb is considered adequate for 
such an attempt. 

The ring speed could be increased significantly by 
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allowing the RI direct access to the MCS-8*s random access 
memory. The RAM ready line makes this approach feasible, 
but then the role of the micro-computer would be reduced and 
the hardware complexity of the Ring Interface would be 
increased. It is planned that later ring interfaces based 
on micro-programmed M03 and TTL logic will allow ring speeds 
on the order of 10 00 Kb. This speed would require buffers 
between slow speed hosts (like the KCS-8/TTY) and the Ring 
Interface. 

3 • Flex ibi lit V 

The ring is designed to move bits. It is not 

dependent on a particular machine's method of representing 
characters or data. Communication is independent of 
processor word length and therefore can support a variety of 
processors and components. Communication between two nodes 
is of course dependent on the particular processor's 
representation of information. But as far as the ring is 
concerned, the transmission is just O's and 1's. 

Flexibility is also achieved with the use of 

micro-computers at the Ring Interface with the host 
processor. The prototype system uses a teletype and HCS-8 
to output messages to the ring for ring testing and 
performance evaluation. This paper also provides MCS-8 
software support for file creation and modification from a 
TTY via the ring to another processor such as the XDS-9300. 
The software system is flexible enough to allow editing and 
execution of the file and dumping of the output back to the 
TTY. 



4 . Si^niElici t and Cost 

To keep cost down and maintain a high degree of 
simplicity, off-the-shelf components are used to the maximum 
extent possible. The ring itself is shielded , twisted pair 
The Ring Interface is the most complex component from 



1 1 



wire. 



the standpoint of construction and design. The TTY connects 
to the HCS-8 using a Universal Asynchronous 
Receiver-Transmitter for serial to parallel and parallel to 
serial conversion. The M3S-8 connects to the Ring Interface 
using two output and two input ports. 



B. ORGANIZATION 

The proposed network architecture is the data ring or 
loop system. This type of system connects all processors 
and/or terminals by a common uni-directional bus. Farmer 
and Newhall [4] at Bell Labs developed a ring designed to 
handle bursty traffic using a bipolar violation technique. 
Control is provided for by a control computer whose function 
it is to monitor and regulate traffic on the ring. The 
introduction of a network controller inserts a critical 
component into the system. If this component fails, the 
ring cannot function. David Farber at the University of 
California, Irvine, [1,2,3] overcame this handicap by 
distributing control amoung the various processors currently 
active in the network. This DCS philosophy was adapted for 
NPS ring organization. 

One feature of the Farmer and Newhall system was 
incorporated into the NPS Ring. Pseudo bipolar violations 
are used for SD.M and EOH indication, SYN, and CTL tokens. 
The Farmer and Newhall ring uses a broadband system based on 
digital PCM. The transmission scheme chosen for the NPS Ring 
is digital. Bipolar signaling is simulated by using logic 
' 1* to logic 'O' and logic 'O' to logic '1' transitions. 

The DCS uses a text bit count as part of the message to 
enable Ring Interfaces to determine ’when text leaves off and 
error checking bits begin. This flexibility enables 
variable length messages to be sent over the ring. One 
problem results from this procedure. If an error should 

occur in the bit field used to indicate text length, 
synchronization would be lost on the ring. The pseudo 
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violation used at NPS consists of sequences of physical 
combinations of one's and zeros's that cannot appear in text 
and are unlikely in error sequences. The type of signallinq 
is digital with data bits (text) requiring two physical bits 
on the ring. The Ring Interface adds redundant bits to 
processor data to form the pseudo bipolar effect, A 
processor 'O' and '1' are encoded as a '01' and '10' 
respectively. This procedure leaves a '11' and a '00' for 
ring violations. Using the '111' violation as part of the 
SOM and EOM tokens gives the NPS Ring variable length 
message capability . 

This method is also considered advantageous for error 
detection. The probability that a '01' sequence on the ring 
(data '0') would be changed into a '10' (data ' 1 ' ) is small. 
It would &be more probable that a data bit would be changed 
into a violation which would be picked up by the RI's as an 
error. Additional error detection is provided by cyclic 
redundancy check bits added to message text by the RI. The 
pseudo bipolar transmission scheme may make these check bits 
unnecessary. If the great majority of errors produce 
violations that can be detected by the RI , the CRC check can 
be removed. This will be proved or disproved by observing 
actual error rates on the ring. Initial RI design will 
provide a means of determining how many errors are detected 
by the CRC that did not produce violations. 
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Fig.1. Possible NPS Ring 

The proposed system is of the type shown in figure 
1. The ring is uni-directional with one node (consisting of 
a host processor and its Ring Interface) in a control state. 
An active node is .defined as a host processor with a process 
(at least one) capable of using the ring as a 
communication's medium. The DCS feature of having processes 
rather than processors as the logical communications entity 
has been retained. A processor may have more than one 
process capable of ring communication. The respective RI is 
"loaded" with the processes current at a particular host 
during the start-up phase. Loading of process names is 
accomplished by providing an address to the Process Name 
Memory (PNH) in the Ring Interface. The bit determined by 
this address is set to a ' 1 ' to indicate an active process 
name. Active process names are deleted by resetting this 



bit 



The node in a control (master) state will either be 
transmitting a message to another process or relaying CTL 
violation tokens to maintain the ring active- Transmission 
of tokens is a function of the Ring Interface and not the 
host or a host process. Active nodes will stop relaying 
control tokens when they receive an SOM from another node or 
when their host has a message for transmission. 

Each node must examine each message header to 
determine if the destination code matches a previously 
loaded host process name. Each node forwards the message to 
the next node even if a destination match occurs. Messages 
are removed from the ring by the source node and replaced 
with violation codes. This insures messages complete a 
circuit of the ring once and only once. Receipt of the 
message is signified by use of match and accept bits 
appended to the message. These bits are made available to 
the sending process and a determination is then made by the 
originator (in the host) as to whether the message is to be 
re- transmit ted. 



2 • Eij}3 Ini 3E f 333 

The purpose of the Ring Interface is to 1) reshape 
and forward signals on the ring, 2) recognize control 
tokens, 3) compare destination process names with processes 
active on its host, 4) signal host and assemble bits of the 
incoming message into 8-bit bytes and pass them to the host, 
5) determine whether overrun has occured, 6) check CBC bits 
for an error in the received message, 7) set the match, 
accept, and bad CRC bits accordingly-, 8) replace the CTL 
violation with an SOM when its host process has a message 
ready for transmission, 9) switch outgoing messages onto the 
ring, 10) calculate and insert CRC bits onto the ring after 
generating an EOM violation after text transmission, 11) 
output a '0* match, a '0* accept, and a 'O' bad CRC bit for 
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resetting by the destination process’ interface, 12) examine 
returning message status bits and make them available to the 
host for examination, and 13) maintain the ring active with 
SYN or CTL violations when in a master status. In addition 
the RI plays a significant role in ring synchronization and 
error recovery. 

This thesis will not dwell on the hardware structure 
of the Ring Interface, but will treat it functionally as a 
"black box". 

3* Role of the Micro- Computer 

As mentioned previously, one purpose of the NPS ring, 
organization was to replace hardware with software where 
possible for maximum flexibility in design. It is 
anticipated that once the Ring Interface functions are firm 
and construction is complete, the RI will be processor 
independent. The RI for the IBM/360 will be the same as the 
RI for the PDP/11. Processor differences will be "absorbed" 
by use of micro-processors (or custom logic interfaces 
later, for higher speed) . 

In the prototype system, the MCS-8 gives a TTY a 
process status. It provides a means of identifying the TTY 
as a process. It allows initializing and changing message 
destination bits. Characters are buffered in MCS-8 RAM a 
line at a time. 'Signalling of the RI to transmit a message 
and making the message available for transmission are under 
the control of NCS-8 software. On the receive side the 
MCS-8 recognizes notification that the RI has a message for 
the TTY. After storing the message in RAM, overrun and CRC 
errors are checked prior to dumping the message to the TTY. 
In the current system only one incoming message (78 
characters or less) is buffered in RAM. Further messages 
are blocked by disabling the receiver section of the RT 
until the message in RAM has been transfered to the 
teletype. In this case the RI would set the match bit and 
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leave the accept bit 'O'. 



4. Host Processors 



The 


ring 


should 


support a 


V ar iety 


of host 


processors. 


The 


protocol 


is flexible 


enough 


to enable 



dissimilar devices to utilize the ring. A host is any 
component capable of either transmitting and/or receiving 
messages via the ring. An example of a transmit-only host 
would be a system status message broadcaster. A node 
desiring system status reports would load the broadcaster's 
process name into its Ring Interface RAH. Periodic status 
reports could be broadcast over the ring and received by 
only those units desiring status reports. A receive only 
example would be a line printer or a card punch. 

The RI could be simplified somewhat for the 

"one-way" host. There would be no need for PAH in the RI for 
process name loading, A receive-only or transmit-only node 
could have its name hardwired in interface logic. A 
receive-only host would not require circuitry for switching 
messages onto the ring, but would still have to decode CRC 
bits and alter message status bits. A transmit-only node 
would not have any use for a destination process name 
decoder. If transmitted messages are periodic, the node 
could even do without CRC/aatch/ accept bit monitors. 

In the general "two-way" host a nucleus of some sort 
would.be required. The nucleus would be required to make 
decisions on system status and take appropriate action. It 
would have to recognize error conditions and initiate 
diagnostic routines for failure localization. The nucleus 
should be as complex as ring reliability requirements 
dictate. If a secondary ring is provided, the nucleus could 
selectively order participating nodes to shift to the 
secondary ring as part of a fault isolation procedure. 

The same basic nucleus would reside on several of 
the major processors. The sophistication of the program 
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might preclude implementation of the nucleus program 
mic ro- processor. 



on a 



18 



III. 



PROTOCOL 



The main objective of the NPS Ring protocol is to permit 
process communications between heterogeneous components such 
that it is possible for each component to communicate 
without knowing the physical placement of the other 
processors. The protocol should be processor independent and 
support variable length messages regardless of code 
structure used in the text of the message. 

The prototype system transmitted message consists of the 
following fields: 

1. Start-of-Hessage token (violation). 

2. Destination process name. 

3. Source process name. 

4. Text. 

5 . Sequence field. 

6. End-of-Message token (violation). 

7. Cyclic Redundancy Check bits. 

8. Hatch bit. 

9. Accept bit. 

10. Bad CRC bit. 

A. DISTRIBUTED CONTROL 

1 • Control Token 1CTL)_ 

The assumption of control of the ring is 

accomplished by replacing a control token with a 

start-of-message violation. The control token is a 
•11101010* physical sequence on the ring. The Ml* header 
in the token is a violation code since it cannot appear in 
text. There is a 9 bit (4 and 1/2 data bit) delay at each 
active node. The delay is necessary to recognize and 

replace the token. Having the bits available at the RI 
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simplifies the logic reguired to make the decision on 
whether a token has been received. Changing from a CTL 
sequence ('11101010') to an S0!1 sequence ('1 1 1000 11') 
becomes just a matter of switching an S0^1 suffix in place of 
the CTL suffix held in the delay shift register. 

An alternate RI design could remove this delay. When 
the *1110' prefix is received the RI could shift the '0011* 
suffix onto the ring and look for a difference between what 
was received and what it transmitted. If no difference is 
detected then a control token was not received and the node 
assumes the SOH belongs to another node. The node then 
returns to the relay state and decodes the message as if it 
was from another source. If a change is detected in the 
suffix, the node assumes it has taken over control of the 
ring and switches a message onto the ring. This approach 
would require more complex timing and control logic at the 
RI than the method selected for the N’PS Ring. In this case 
the receiver section of the RI about to assume control must 
be phase- locked with its transmitter since bits are being 
modified as received. 



Synchronization 



A major problem in the distributed control approach 
to ring communications is the synchronization of active 
nodes. This is a three part problem. The first part is 
initial synchronization. Next is maintaining synchronization 
and loss-of- synchronization (LOS) recovery. The third is 
re-synchronization of the ring when a node either leaves or 
joins the active ring. 

Under steady state ring conditions, the following 
protocol is observed. The master node will broadcast a CTL 
token and start a timer waiting for its receiver to detect 
the token. If the CTL token is not received prior to 
expiration of the timer, the RI will transmit an SYN token. 
This SYN time-out is different for each RI with enough 
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separation to insure only one will expire during any one 
ring cycle. A ring cycle is defined as the maximum possible 
ring delay in bits, divided by ring speed in bps. This 
would be about .23 seconds at 10Kb ring speed and 256 nodes 
on the ring (9 bits delay per node) . On receipt of an SYN, 
CTL, or SOH token, each node resets its SYN timer. When a 
node's SYN timer expires, it transmits an SYN and assumes 
control of the ring. The main purpose of the SYN and SYN 
time-out is to insure control of the ring is maintained. If 
the master node receives its SYN prior to expiration of the 
timer, after its SYN T/0 again expires, it transmits a CTL 
token. This insures only one CTL can exist on the ring at 
the same time. 

When a CTL is replaced by an SOM, control of the 
ring shifts to the node making the replacement. After 
receipt of an SOM, SYN time-out will not occur until the 
ring goes idle. The transmitting node removes its own 
message from the ring. When it receives the match, accept, 
and bad CEC bits, it transmits a CTL token and shifts to the 
relay mode. In the relay mode only valid CTL, SYN, and SOM 
tokens are passed to the next node. This insures noise does 
not get continuously propagated around the ring. If a token 
is altered by noise, it will be immediately removed from the 
ring, since the next node seeing it will not recognize the 
sequence as a token and will not relay it. Synchronization 
will be regained when an SYN timer expires and a node 
transmits an SYN token. When an SOM is received, the RI 
transitions to the "receive" mode and continues to forward 
the message to the next node. If an SOM is altered by 
noise, the message will be removed from the ring. 

Initial ring synchronization occurs as above by 
active nodes initiating an SYN T/0 and waiting. The first to 
have its time-out expire will transmit an SYN ('1 1 100010'). 
When the SYN is received by the other nodes, they reset 
their timers. It is still possible for two SYN's to exist 
on the ring at the same time. Since each node uses its 
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unique time 


to initiate the first CTL 


token, only one 


CTL 


can exist at 


any given time and 


synchronization 


is 


guaranteed . 


This prevents an "after 


you"/"no, after 


you " 


condition f rom 


occuring. 






part 


two of the synchronization problem 


is 



maintaining synchronization. With no message transmission 
(just SYN or CTL violation tokens) , synchronization occurs 
with each violation. During message passing synchronization 
occurs on SOK and CTL violations. Loss of bit 
synchronization would result in seeing violations in text. 
For example, the data sequence '100111' would be encoded as 
'100101101010' on the ring. Being one bit out of 
synchronization would produce at least two pseudo-bipolar 
violations, but no violation token would result. The 
selection of the SYN, SOM, EOM, and CTL violations as 
eight-bit strings with a '111' sequence for a prefix insures 
that these codes cannot be duplicated by synchronization 
errors occuring in message text. Violations ('00' or '11') 
could occur due to single bit errors in text. Therefore, 
these violations cannot be used for synchronization. Tn 
either case if a violation occurs in text, the CRC check is 
assumed to fail and the RI looks for a legal violation code 
on which to re-synchronize. 

The third case of the synchronization problem occurs 
when a node leaves or joins the ring, k node may leave due 
to a normal termination or some failure (or on command of a 
fault isolation routine). Termination removes the 9 bits of 
delay at that node. The bits in the node's delay shift 
register are lost. If termination occurs in text at a data 
bit boundary, ring synchronization would not be affected. 
The CRC check would fail and the message would be 
re-transmitt ed. If the delay occurs between a data bit 
boundary a '11' or '00' violation would be produced which 
would be detected by the RI's. If the delay is removed 

while part of a token was in the register, an LOS condition 
results. This situation is handled the same as when a node 
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joins the ring and introduces an extra delay between token 
boundaries. Nodes join the ring in the relay node and if 
the ring is idle, the incoming node will start its SYH 
time-out and ring synchronization would not be affected. If 
a token is altered by the introduction of the new node's 
delay, the invalid bit string would be removed from the ring 
by the next node in sequence and an SYH timer expiration 
will re-synchronize the ring. 

B. RING INTERFACE/KICRO-GOMPUTER PROTOCOL 
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Fig. 2. Prototype System 



The MCS-8 system used in the prototype (Figure 2) is 
built up from INTELLEC-8 modules. Communication vjith the 
Ring Interface is accomplished using two input and two 
output ports. One input and one output port are used for 
message transfer with the two remaining ports used for 
control and status information. 

1 . Messa ge Tr an smiss io n 

When the MCS-8 has a complete message in RAH, it 
loads the data output port with an 8-bit destination code 
and signals the PI via the XHTR ENABLE line. The RI waits 
for a control token and replaces it with a start- o f- messa ge 
token. The PI then latches the first byte of information 
(the destination code) and notifies the HCS-8 that it has 
the byte using the XHTR READY line. The BYTE AVAIL output 
line is used by the HCS-8 both to indicate that the RI has 
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received the last byte of a message and to notify the RI 
that the next byte is available. The Ring Interface uses 
this line to make the decision on whether an ’’overrun" error 
has occured. An overrun condition exists on transmission if 
the micro-computer (or other host) cannot make bytes 
available fast enough for the RI to maintain message 
continuity on the ring. This error should not occur under 
normal conditions, since the speed of the ring must be 
limited to the data rate of the slowest host. 

When the complete text has been made available to 
the RI, the MCS-8 loads a serial bit into the output port 
and signals "serial bit available" (message complete) by 
resetting the XHTR EKAEL5 line. After transmitting the 
serial bit, the RI switches CRC bits onto the ring followed 
by match bit, acce pt bit , a nd bad CRC bi t . On return of 
these status bits, the RI makes them available to the MCS-8 
and transmits a CTL token. On the basis of the message 
status bits, the HCS-8 can order re-transmission of the 
message or make its RAH buffer available for the next 
message from its host. On an accept-fail condition the MCS-8 
will attempt' to transmit the message a second time. If that 
attempt fails, a transmit-error message is typed at the TTY. 

2 • JESSSiycr Protocol 

When a Ring Interface detects an SOM, the RI 
interprets the next 8 bits as the destination process name. 

A match is then attempted between the destination code and 
the active process names on the RI’s host. If a match, 
occurs the RI makes the destination byte available to the 
MCS-8 and signals start-of -m essage using the SOM line. On 
detection of the SOM by the micro-computer, the destination 
code is stored in RAM and acknowledged using the BYTE 
RECEIVED line (the same line that was used for BYTE AVAIL 
during transmit operations) . The RI then resets the SOM line 
to acknowledge storing of the last byte. The MCS-8 then 
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waits for another logic '1' signal on the SOM line 
indicating that the next byte is available. The RI can again 
make determination on the occurance of overrun errors. 

After the EOH token is detected by the RI, it will 
signal end-of-message to the micro-computer, using the EOH 
line, and set OVERRUN and CRC ERROR lines accordingly. The 
RI also will set the match, accept, and bad CRC bits based 
on the detected errors. The micro-computer can then decide 
whether to ignore or transfer the message to its host. 

C. MICRO-COMPUTER/HOST PROTOCOL 

The host in the Prototype System is an ASR-33 Teletype 
using an MCS-8 to attain processor status. The intention was 
to provide minimal host that would have its entire nucleus 
implemented on a micro-processor. The minimum capabilities 
would have to include message origination and a receive 
capability. 

The teletype can be used to (1) load source process 
names into Ring Interface RAH, (2) load a destination name 
into MCS-8 RAM, (3) transfer up to 78 characters as message 
text to MCS-8 RAH, and (4) order transmission of a message. 
As a receiver the TTY can accept messages in USASCII code of 
up to 78 8-bit characters in length. 

As mentioned previously, serial to parallel and 
parallel to serial conversion is handled using an Universial 
Asynchronous Receiver-Transmitter (UAR-T). Characters from 
the TTY are made available to one of the MCS-8’ s input ports 
(via the UAR-T). The UAR-T signals character availability 
using the Data Available (DA) line. When using the 
INTELLEC-8 I/O Module, character acknowledgement is 
automatic" upon execution of the input instruction on that 
port. When the UAR-T is used alone, the Reset Data 
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Available (RDA) line must be strobed to permit acceptance of 
the next character from the TTY. The UAP-T also provides 
status pins for parity error, framing error, and overrun. 
The MCS-8 interprets a carriage-return character (C/R) as a 
message or command terminator. 

2* P roces s Name Loading 

The prototype system permits receive process name 
loading into Ring Interface Process Name Memory (PNM) using 
the teletype. The RI matches received message destination 
codes with process names previously loaded into its PNM by 
its host. This procedure allovfs a host to have strict 
control over what messages it sees. 

3 . Com mand L an g ua ge 

The MCS-8 system supports a Command Language for the 
passing of commands from the TTY to the Ring Interface. The 
MCS-8 scans the first non-blank character from the TTY 
message for a •$' command character. TTY messages starting 
with a $ are always interpreted as commands and will not be 
transmitted over the ring. The character following the $ 
determines command type. Additional characters, if needed, 
are arguments to the command type. Arguments are separated 
from the command' type with the ' = * character. A list of 
current commands and their meanings follow: 



Command Mea ni ng Ar qu ments 

D Destination Process name 

name set 

R Remove receive Process name 

process name 

S Source/Receive Process name 

name set 

A Activate RI 



(join the ring) 

E Exit the ring 

For example, typing • $S=C* followed by a carriage 



26 



return causes the MCS-8 to load the 8-bit (7-bit + even 
parity) USASCII code character ”C’' (43 hex) as a valid 
receive code into RI PNH. This same character code will be 
stored in MCS-8 RAH as the source field of outgoing 
messages. Up to 256 receive codes can be loaded into RI 
RAN, but only the most recently entered will be use.d as the 
source code on message transmission. Internally, when the 
MCS-8 receives the carriage return, it loads its RI output 
port with the character and outputs a logic '1' on the SET 
line to the RI. The RI uses the character as an address to 
its PNH and sets the bit determined by this address to a 
logic '1'. The RI acknowledges both the 's' and 'r* 
commands using the XHTR PBADY line. 

A more general system would interpret the characters 
following the equal sign as a based number. Using the 
USASCII codes for process names limits valid names to those 
characters (less rubout and carriage-return) available on 
the ASR-33. This is no real limitation to the test and 
evaluation role of the MCS-8/TTY host. 
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MCS-8 WITH TTY AS A HOST 



A. HARDWARE CONFIGURATION 
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Fig. 3. /mCS-8/TTY Host 



Figure 3 shov;s the major components of the prototype 
MCS-8/TTY host. The micro-computer svstem is built up using 
INTELLEC-8 modules. The IKTELLEC-8 Central Processor Module 
(8001-1 CPU) , Input/Output Module, PROM Memory Module, and a 
custom 256X8 bit random access semiconductor memory (RAM) 
make up the KCS-8 system. The 8008-1 CPU executes 
non-memory referencing instructions in 12.5 microseconds 
when operated from the 800KHz clock contained on the CPU 
Module. The MCS-8 program requires 5 ROM's and 1 RAM. 

The INTELLEC-8 I/O module contains the necessary TTY 
connections, the Universal Asynchronous Receiver- 
Transmitter, and the interface circuitry to the input and 
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output ports. The TTY is a comwon carrier TWX Terminal 
Model ASR-33 (8- level USASZII code, 110 bps). 

2- Universal Asynchronous Receiver Transmitter ( U AR- T ) 

The UAR-T is a general purpose, programmable MOS/LSI 
subsystem integrated on a single monolithic chip. It is 
used to convert asynchronous serial binary characters from 
the TTY to an 8-bit parallel format for input to the MCS-8. 

The UAR-T also converts 8-bit parallel binary 
characters to serial, asynchronous output with start and 
stop bits added. Both the receiver and transmitter are 
double buffered. The I/O module provides automatic Receive 
Data Enable (RDE) , and Reset Data Available (RDA) logic to 
the UAR-T when an input instruction is executed on the 
MCS-8. Data Strobe (DS) is automatic when an output 
instruction is executed. Automatic strobing is accomplished 
by MCS-8 instruction decoding within the I/O module. 



B. S0FTV?ARE SYSTEM 

The program for the MCS-8/TTY host is included as part 
of this thesis. It is programmed in PL/H [6]. Compilation 
into MCS-8 object code was acomplished on the IBM- 360/67 
using CP/CMS. Execution of the program was simulated using 
the FORTRAN IV program INTERP/8 [5]. This prograni simulates 
the 8008 CPU and provides monitoring commands to aid in 
program development. INTERP/8 accepts machine code produced 
by PASS 2 of the PL/M compiler, along with execution 
commands from the CP/CMS terminal. It also provides tracing 
features that allow CPU monitoring. 

Procedure MAIN is the program executive routine. The 
basic loop consists of checking (1) the teletype for key 
depression and (2) the Ring Interface for message 
destination match with host process name (i.e., message for 
this host) . 
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I • Pr ogram Fl ow 

When a TTY key depression is detected (logic '1' on 
the 'DA' line from the UAR-T) , the character is fetched from 
the UAR-T using Input port 0. The 'DA' line is reset 
automatically when the input instruction is executed, 
thereby re-enabling the UAR-T for the next character from 
the TTY. Messages from the TTY are accessed a character at 
a time and are terminated by the carriage return character. 
Messages are of two types, either command (first character a 
'$') or messages for transmission. 



Port Bit 



Use 



INO 0-7 



TTY data line 
from UAR-T 



IN 0 

1 
2 

3 

4 

5 

6 

7 



Character available 
from UAP-T 

Transmit Buffer Empty 
on UAR-T 

SOM/Next Byte Available 

from RT 

ROM from RI 

RVCR ov erru n/Match 

RVCR error (CRC) /Accept 

Transmitter (RI) Ready 



IK2 


0 

1 


OUT1 


0-7 


OUT2 


0 




1 




2 • 



3 

4 

5 

6 
7 



Ring data line from RT 
Ring data line from MCS-8 



Ac tiva te/Exi t 
Disable PI Receiver 
Byte Received from RI 
Byte Available to RI 
Enable PI transmitter 
Set host process name 
Delete host process name 



0UT3 0-7 



TTY data line from MCS-8 



Fig. 4. IiCS-8 I/O Port Usage 



Figure 4 lists the MCS-8 input and output port 
usage. When a command message is received, output port 1 is 
set with the process name, if required, and control signals 
are sent to the Ring Interface using output port 2. When a 
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message for transmission is received, the first byte is made 
available to Output port 1 and the RI is signalled using the 
XMTR ENABLE line. Procedure XMIT then completes message 
transfer to the RI. 

The RI signals message received from another host 
using the SOM line. MAIN calls on procedure GETMSG to 
transfer and store bytes from the RI. The RI mahes the 
determination of whether an error (overrun or CRC) has 
occured and sets the match, accept, and bad CRC bits 
accordingly. On an "accept” condition, procedure PRINTMSG 
is called to dump the message to the TTY. 

2. File Codes 



System flexibility is realized in the transmission 
of messages. Messages and message format are source 
process/destination process dependent. A possible 
application of the KCS-3/TTY host to the operational ring 
could be realized by the use of a message format using file 
codes. For example, with appropriate software support on 
the XDS-9300 or IBM-360, the MCS-8/TTY host can be used to 
create and execute files on a remote processor. The 
transmitted message would consist of a file code and an 
argument list. For example, 'NEW FILE1,NPS' could order the 
creation of a new file named 'FTLE1' with a protect key of 
•NPS'. After a file has been opened, file codes for "append 
to file," "delete current line," "change current line," 
etc., could be used for file creation and editing. File 
manipulation codes could also be implemented on the 
processors. "Erase file," "copy to printer," and "copy to 
TTY" are just a few. 

With additional software support from a processor, 
the HCS-8/TTY host could be used in a desk calculator mode 
using appropriate calculator codes. Host calculator 
functions’ could be performed locally with message 
transmission only when required (such as for transcendental 
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functions) 
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V. 



CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

A ring-switched computer network, using micro-computers 
at the host interface to the ring, can be designed to 
satisfy the requirements of reliability, flexibility, 
simplicity, and low cost. The major sacrifice in the 
prototype system is in the system bandwidth do to the 
relatively slow speed of the micro-computer, but the 
benefits in flexibility of design and system simplicity 
outweigh this deficiency. The DCS type organization with 
its distributed control philosophy is a reliable approach to 
network architecture. Difficulties in the DCS with regard 
to synchronizing and detecting loss of synchronization have 
been overcome in the NPS Ring architecture at a sacrifice in 
ring speed. The pseudo-bipolar violation concept provides 
the capability for variable length messages, ring 
synchronization, and control passing. The fact that these 
violations cannot appear in message data, forms a reliable 
basis for network protocol. 

The MCS-8/TTy host provides a flexible access to the 
ring for system evaluation. The software provided will 
support a number of TTY modes, depending on the amount of 
interpretive support available on the major system 
processors. 

B. RECOMMENDATIONS 



Further work is required in several areas. It is 
recommended information security on the ring be 
investigated. The ring as it stands has no real protection 
on data flow. All data passes through each active node. 
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The present. system does not provide for a software 

diagnostic routine to aid in fault isolation. Process names 
could be reserved for this purpose. Nucleus programs could 
communicate directly using these process names to, for 
example, selectively order an exit from the ring. Provision 
should be made to collect data on system performance. The 
average time it takes to get control of the ring for 
transmission, the number of messages requiring 

re-transmission, and the mean time between LOS conditions 
are considered important in determining system 

effectiveness. 
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MCS-/8 NUCLEUS PROGRAM 



/>♦ 

PASSl CCMPILER OPTIONS 

*/ 

$KEM 

$RIGET=80 

$hICTH=120 

/* 

GLOBAL VARIABLES 

*/ 

DECLARE (MSGIN,MSGOUT ) (80) BYTE; 

DECLARE (1NCCUKT,CUTC0UNT) BYTE; 

DECLARE (CLTl ,0L72 ,0UT3) BYTE; 

DECLARE (CEAR,C ARRIAGE$RETURN,RUBCUT) BYTE 
INITIAL (OCDH,CODH,OFFH) ; 

DECLARE LIT LITERALLY ’LITERALLY' , DCL LIT 'DECLARE' 
CCL FO LIT *0', PI LIT 'l», P2 LIT *2', P2 LIT »3'; 
DCL TRUE LIT 'OFFH', FALSE LIT 'O'; 

CCL (SER lAL , ACCEPTED) BYTE; 

DCL (DCHAR,DEST INATION, ACTIVATE) BYTE; 

DCL (EXIT, DELETE , SET, CHANGECK) BYTE; 

CCL (COMMAND, EQUAL) BYTE INITIAL ( FALSE , FALSE ) ; 

DCL LINE$FEED BYTE INITIAL (OAH); 

/* 

G E T $ M S G 

*/ 

/* 

GET MESSAGE FETCHES BYTES FROM THE RI 
LNTIL AN EGM IS DETECTED BY TFE RI. 

TFE PROCEDURE THEN WAITS FOR THE 
PI TC MAKE CRC AND OVERRUN STATUS 
ens ABAILABLE. 

CN RETURN IF 'INCOUNT' IS GREATER 
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IH/iN ZERC THEN THE MESSAGE RECEIVED 
IS ERROR-FREE AND CONTAINS ‘ INCOUNT' 
NUMBER CF BYTES. 



4 / 

GETJMSG: FRCCECURE; 



=♦/ 



*/ 



/* 

/* 



RING INTERFACE HAS SIGNALLED MSG RECEIVED 
VIA INPUT PORT 1 BIT 2 SET AT LOGIC • 1' 



INFUT PORT 2 HAS THE NEXT BYTE FROM THE RING 
INPLT PORT 1 BIT 3 AT LOGIC '1' 

INDICATES EOM DETECTED BY THE RI. 

INPLT FORT 1 BIT 2 AT LOGIC *1' 

INDICATES NEXT BYTE AVAILABLE. 

CLTFLT PORT 3 BIT 4 AT LOGIC 'O' 

INDICATES BYTE STORED IN RAM. 

CUTFLT PORT 3 BIT 4 AT LOGIC M' 

INDICATES MCS-8 HAS RECCGNIZED LCGIC *1* 

AT INPUT PORT I BIT 4 FOR NEXT BYTE AVAIL. 



CCL J BYTE; 

STCRE’ first BYTE IN RAM */ 

MSC-IN=INPUT(P2) ; 

J = 1 ; 

INFORM RING INTERFACE THAT BYTE HAS BEEN STORED 

GMLCGFi: OUT 2 , OUTPUT ( P2 J =OLT2 OR lOH; 

RETURN IF RING INTERFACE HAS RECEIVED AN EOM 
IF (INPUT(Pl) AND OSH) > 0 THEN GO TO GETSXIT; 

WAIT UNTIL NEXT BYTE IS AVAILABLE 
GMLCCP2: 

IF (INFLT(Pl) AND lOH) = 0 THEN GO TO GMLOOP2; 
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NOTIFY RI BYTE AVAILABLE ACKNOWLEDGED */ 



/« 

Cn 2 ,QLTFUT(P 2 ) = CUT2 AND OEFH; 

PSGIM J ) = INPUT(P2) ; 

J=J+1 ; 

GO TO gploopl; 

GETIXIT: 

CHECK RECEIVE STATUS FLAGS -- OVERRUN AND CRC 

INPUT FCRT I BIT A AT LOGIC »l* INDICATES OVERRUN 
INPUT FCRT 1 BIT 5 AT LCGIC 'I* 

INDICATES CRC CHECK FAILED. 

’f/ 

IF (INFUTIPI) AND 30H) > 0 THEN INCCUNT=0; 

ELSE INCOUNT=J; 

RETURN; 

END GETIVSG; 

/* 

PRINT$CHAR 

/* 

PRINT CHARACTER OUTPUTS A CHARACTER 
IN USASCII CCDE TO OUTPUT PORT 
F2. NOTE THAT MCS-8 OUTPUT PORTS 
CGNPLENENT DATA. 

«/ 

PFINT$CF,AF: PRCC ECUR E ( PCHAR ) ; 

CCL PCHAR BYTE; 

/* 

WAIT FOR TRANSMITTER BUFFER REGISTER EMPTY ON UAR-T 
TBE=*0* IMPLIES NOT EMPTY 

«/ 

FLCCFl: IF (INPUT(Pl) AND 02H)=0 THEN GO TO PLOOPl; 

/* 

LCAC CHAR INTO OUTPUT PORT 0 
OUTPUT ( P3 }=PCFAR XOR OFFH; 
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NC7E: UAR-T RESETS TBE TQ LOGIC *1’ WHEN TRANSMITTER 

REGISTER IS RcACY FOR NEXT CHAR 

4 / 

RETUB^ ; 

END FRINT$CH/iR; 

X K I T 

*/ 

/=» 

TRANSMIT (XMIT) MAKES MESSAGES FROM 
THE TTY /IVAILABLE TO THE RI FOR 
TRANSMISSION. AFTER TRANS. IS 
CCMPLETE, IT WAITS AND CHECKS 
MATCH, ACCEPT, AND CRC BITS TQ 
DETERMINE WHETHER THE MESSAGE 
FAS BEEN RECEIVED. 

MESSAGES NOT RECEIVED WILL EE RE- 
TRANSMITTED ONCE PRIOR TO AN 
ERROR CON'OITICN. ON RETURN 

•ACCEPT* IS TRUE IF TRANSMISSION 
WAS SUCCESSFUL. 

♦ / 

XMIT: PRCCECURE; 

CCL XCCLNTEYTE; 

/« 

MAKE DESTINATION AVAIL TO RI AT OUTPUT PORT I 

«/ 

ACCEPTED=FALSE; 

XMIT$START: 

OUTPUT (Pi)=MSGCUT; 

/* 

NOTIFY PI MSG FOR TRANSMIT 

*/ 

OUT2,OUTFLT(P2)=OUT2 AND ODFH; 

/* 



38 



CLTPUT ENTIRE MSG 



CC XCGUKT=1 TC OUTCCUNT; 

/* 

VsAIT FOR RESPONSE FROM RI THAT 
LAST BYTE WAS RECEIVED. 

’♦Z 

XLCOFtIF (INPUT(Pl) AND 40H) = 0 THEN GO TO XLOOP 
GLT2,CLTFUT(P2)=0UT2 OR lOH; 
OLTPLT(Pl)=MSGOUT{XCOUNTl ; 

/* 

INFCRP RI NEXT BYTE AVAILABLE 

=»/ 

OUT2,CUTPUT(P2)=OUT2 AND OEFH; 
f.ND; 

/t 

SERIAL BIT RECUIRED NEXT 
RESET MSG FCP TRANSMIT FLAG 

SIGNIFIES SERIAL BIT COMING. 

♦ / 

XLCCPl: IF (INPUT(Pi) AND 4CH) = 0 THEN GO TO XLOOPU 

CUT2,CUTPUT (P2 ) = OUT2 OR lOH; 

CLTPLTIFl )=SEPIAL; 

/« 

WAIT FOR MATCH/ACCEPT BITS RECEIVED 

=*/ 

XLCOP2: IF (INPUTIPIJ AND 40H) = 0 THEN GO TO XL00P2; 

/* 

IF MATCH OR ACCEPT BIT NOT SET RETRANSMIT MSG ONCE 

*/ 

IF (INFLT(Pl) AND 30H) < 20H THEN 
IF (SERIAL = 0) THEN 
CC; 

SERIAL=l; 

GO TC XMITT.START; 

ENC ; 
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ELSE GO TO XOUT; 



f^ESS/»GE ACCEPTED 
i/ 

ACCEP1EC=TRUE ; 

XOLT : 

SERI/iL = 0; 

RETURN ; 

END XMIT; 

/>* 

PRINT$MSG 

■>»/ 

PRINT MESSAGE OUTPUTS RECEIVED MESSAGES 
TC THE TTT VIA THE UAR-T. 



«/ 

PRIKT$MSG: PRCCECURE; 

CCL FPCM4MSG CATA ('FROM • ) *, 

CCL FCCLNT BYTE; 

/* 

OUTFIT CARRIAGE RETURN TO TTY 
CALL PRINT $CHA P ( CARRIAGE$RETURN ) ; 

/■Sf 

OUTPUT 'FRCM « 

=♦/ 

CO PCCUNT=0 TC 4; 

CALL PRINTICHAR(FROMMSG(PCCUNT ) ) ; 
END ; 

CLTFUT SCUFCE NAME 
CALL FRINTCHAR(MSGIN( 1) ) ; 

/=» 

OUTPUT CARRIAGE RETURN 
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CALL FRINT1CHAR(CARRIAGERETURN J ; 



/* 



GL1FLT KESSAGE 



CC PCCLM = 2 TO INCOUNT; 

CALL PRIN7$CHAR(MSGIN( PCGUM) ) ; 

ENC ; 

RETURN; 

END PRINTiPSG; 

/« 

E R F C R 

« / 

/* 

ERRCR PRINTS 'ERROR' FOLLCWED 
EY TEE ERROR NUMBER GIVEN AS 
TEE CALLING ARGUMENT. 

•*/ 

ERROR: PR CC E CUR E ( ERRCRNUM BER ) ; 

CCL (EPRCFNUMEER, ECOUNT) BYTE; 

CCL ERPCRiMSG DATA ('ERROR •}; 

/* 

CLTFLT CARRIAGE RETURN 

it/ 

CALL FRINTCEAR (CARRIAGERETURN) ; 

/♦ 

PRINT 'ERROR' FOLLOWED BY ERROR NUMBER AT TTY 






DO ECCUNT=C TO 5; 

CALL PRINTCHAR(ERRORMSG(ECOUNT) ) ; 
ENC; 

CALL FRINTCEAR(ERRORNUMBER) ; 

RETURN ; 

END ERROR; 

/4 












*/ 



MAIN PROGRAM 



CCL I BYTE IMTIAL (2); 

/•* 

CLE/!P CLTPLT PORTS TO LOGIC 'O' 

NCTE: ALL OUTPUT PORTS CCMPLEHENT DATA 

*/ 

CUT3, OUTPUT (P2 ) , OUT2, OUT PUT ( P2 ) =OFFH ; 

RDA : 

IF (IhPLT(Pl) AND OlH) > 0 THEN 
/* 

FETCH CFAR FROM UAP T 

DC ; 

CFAP=INPOT(PO) ; 

IF CH^R <> CARRIAGE$RETURN THEN 
CC; 

IF CHAR <> RUB$OUT THEN 
DO; 

MSGCLT (I )=CHAR; 

IF I = 2 THEN 
CC ; 

IF CHAR = • • THEN GO TO SKIP; 

IF NOT COMMAND THEN 
DC; 

IF CHAR='$* TFEN COMMAND=TRUE ; 

ELSE 1=1+1; 

END; 

ELSE DO; 

IF CHANGECK TFEN 
DC; 

CALL ERROR {'2»); 

SET, DELETE, DESTINATION, ACTIVATE, EX IT 
COMMAND, EQUAL,CHANGEOK=FALSE; 
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END 



IF (SET OR DELETE) AND EQUAL THEN 
CO; 

CUTPUTtPl )=CHAR; 

IF SET THEN M SCOUT ( L ) =CHAR ; 
CHANGEOK=TRUE; 

END; 

ELSE IF DESTINATION AND EQUAL THEN 
DC; 

dchar=char; 

CHANGEOK=TRUE; 

END; 

ELSE IF ACTIVATE OR EXIT THEN 
CALL ERROR! •2* ) ; 

ELSE IF CHAP = *A' THEN A CT I VAT E=TRU E 
ELSE IF CHAR='E* THEN EXIT=TRUE; 
ELSE IF CHAR='S* THEN 
SET=TRUE; 

ELSE IF CHAR='D» THEN 
DESTIKATICN=TRUE; 

ELSE IF CHAR='R' THEN 
DELETE=TRUE; 

ELSE 

IF CHAR= •=• THEN 
EQUAL=TRUE; 

ELSE 

CALL ERROR( *2* ) ; 

END; 

END; 

ELSE I=I+l; 

END; 

ELSE IF (I>2) THEN I=I-l; 

/* CHAR IS RUBOLT AND 1=2 */ 

ELSE IF CHANGEOK THEN CHANG EOK=FALS E ; 

ELSE 

SET, DELETE, DESTINATION, ACTIVATE, EXIT, 



A3 



COMMAND,EQUAL ,CHANGECK=FALSE; 

END; 

ELSE IF (I>2) THEN 

cc; 

CLTCCUNT=I ; 

CALL XMIT; 

IF NOT ACCEPTED THEN 
CALL ERROR! • 1* ) ; 

OLTCOUNT=0; 

1 = 2; 

END ; 

/>» CFAR = C/R AND 1=2 */ 

ELSE DC; 

IF CHANGEOK THEN 
DO ; 

IF SET THEN 

OUT2,OUTPLT(P2) =OUT2 AND OBFH; 
ELSE IF DELETE TFEN 

0UT2, OUTPUT (P2) =0UT2 AND 07FH; 
ELSE MSGOUT=DCHAR; 

END; 

ELSE IF ACTIVATE THEN 

OUT2,OUTPUT(P2 )=0LT2 AND OFBH; 

ELSE IF EXIT THEN 

0UT2,0UTPUT(P2> =0UT2 OR OAH; 

ELSE GO TO SKIP; 

SET,DELETE,DESTINATICN,ACTIVATE,EXIT, 

ccmkand,ecual,changeok=false; 

WAIT FOR ACKNGViLEDGEMENT FRCM RI 

PNAME: IF (INPUT(Pl) AND 40H) = 0 THEN 
GO TO PNAPE; 

END; 

ECHC LAST CHARACTER TO TTY 
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skip: if ch^p=carriage$return then 

CALL PRINTCHAR(LINE$FEED) ; 

ELSE CALL PR INTCHAR (CHAR ) ; 

END ; 

/« 

FAS Rl RECOGNIZED MESSAGE FOR THIS PROCESS 

IF (INPUT(Pl) AND 04H) > 0 THEN 
CC ; 

CALL GETMSG; 

IF ((INCCUNT>OJ AND (CHAR=GARRIAGE$RETURN ) ) THEN 
DC ; 

CALL PRINT$MSG; 

INCCLNT=0; 

END; 

END; 

GC TC RDA; 

EOF 
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